Confluence - популярный и удобный инструмент для работы с требованиями. Однако при работе с ним можно столкнуться с такими проблемами и недостатками, как:

1. Требования могут дублироваться на разных страницах. В случае изменений требования необходимо скорректировать на всех страницах, где они указаны.
2. Неудобные механизмы указания ссылок.
3. Нет возможностей связывания требований между собой и сбора отчета по ним.

Эти проблемы можно решить с помощью Requirements Yogi - набора плагинов Confluence, предназначенного для управления требованиями. Данный инструмент позволяет:

1. Присваивать требованиям уникальные идентификаторы и свойства.
2. Избежать дублирования требований.
3. Связывать требования между собой.
4. Создавать отчеты по требованиям, зафиксированным на разных страницах.

Кроме того, плагины Requirements Yogi можно использовать не только для требований. Они не менее эффективны при работе с системными ошибками.

В докладе я поделюсь своим опытом работы с Requirements Yogi при ведении реестров требований и ошибок.

Команды на “удаленке”, помимо созвонов, постоянно пользуются чатами для общения в группах и между собой. Написанные второпях короткие сообщения воспринимаются неоднозначно: сложно понять смысл, когда не видишь эмоцию собеседника, не слышишь интонацию и не до конца понимаешь значение написанного.  

На мастер классе мы поговорим, как сделать так, чтобы мы лучше понимали, что пишут нам и сами делали так, чтобы лучше понимали нас. 

Мы поговорим про сокращения, аббревиатуры, эмотиконы, обращения, междометия, и акцентируем внимание на эмодзи, как важном инструменте выражения чувств в онлайне. 

Мы обсудим как общаться в чатах с коллегами и заказчиками не только из России, но и из других стран. И потренируемся, используя упомянутые инструменты.

Тематика общедоступная, и слушателем может быть абсолютно любой человек: и специалист в IT, и маленький ребенок и взрослый человек, не имеющий отношения к анализу и IT в целом.

Будет смешно и весело, приходите!

Примерное время мастер класса: 1:20 - 1:30 

Часто нефункциональные требования для аналитиков и заказчиков - как самая некрасивая комната в доме. Все остальные комнаты ухоженные, с цветами в вазах, фруктами на столах и кружевными салфетками. Вы вдвоем ходите по дому, любуетесь, а мимо этой комнаты проходите быстрым шагом и не оборачиваясь. Не задумывались, почему так происходит?

По моему опыту, нефункциональные требования часто воспринимаются как не очень нужное дополнение к действительно важным требованиям - функциональным. Даже в названии они как будто противопоставляются функциональным. Заказчик не понимает их ценности, а аналитик не участвует в их реализации. Поэтому однотипные разделы "требования к обеспечению", "требования к перспективам модернизации" и "требования к защите от потери данных" просто копируются из документа в документ, а загадочные "девятки" и "время обработки запроса" интересны только техническим специалистам.

Хватит это терпеть! На мастер-классе мы поговорим о том, что принято называть "НФТ" с позиции их реальной ценности. Обсудим, почему и зачем они действительно важны, и как их можно (и желательно - нужно) выявлять. И попробуем все это на практике - участники мастер-класса будут пытать самых общительных в мире "заказчиков", чтобы собрать НФТ, зафиксировать их и обсудить друг с другом.

Формат: бизнес-игра

Бизнес-аналитики решают задачи, связанные с оптимизацией бизнес-процессов, улучшением управления персоналом, повышением качества продукции и услуг. Через бизнес-анализ исследуют данные и выявляют проблемы, чтобы разработать наилучшие решения для повышения эффективности деятельности компании.

Специально для ЛАФ мы собрали группу «Head of BA и Business Architects» и разработали алгоритм и карту допроектного исследования проблем и контекста и хотим вас с ней познакомить в формате деловой игры. Мы смоделировали бизнес-кейс, с которым погрузимся в реальные условия работы бизнес-аналитиков и вместе разберёмся в применении нашего алгоритма для любых задач бизнес-анализа.

В ходе игры участники смогут:

- отработать на практике одну из стратегий выявления бизнес-возможностей, анализа и обоснования предлагаемых решений;

- получить опыт создания спецификации бизнес-требований;

- потренировать навыки командной работы и принятия решений в условиях неопределенности.

- обсудить эффективность процессов бизнес-анализа и применения выбранной стратегии;

Регистрация

Время игры - 90 минут

Количество участников - 20+ человек

Требование к помещению - закрытое помещение куда поместится 25-30 человек. Есть столы и стулья. Возможно потребуется проектор.

Если вы хотите принять участие в бизнес-игре, то для вас подходит подходящий вариант:

• Иметь опыт работы в области бизнес-анализа.
• Проводите изменения в большой компании или хотите в этом разобраться.

Как измерить KPI аналитиков при нашей многозадачности, сложной прогнозируемости объемов работ, постоянных изменениях и бесконечных зависимостях от других?

Для многих (даже ведущих) аналитиков эта тема так и остается в планах развития, и все никак не превращается в рабочую практику. И на это есть причины. Не так-то просто перевести лаконичную, казалось бы, теорию в, положительно влияющую на результаты работы практику.

Как аналитик и руководитель, отвечающий за совокупный результат работы команды - представляю вашему вниманию доклад "Практические подходы к измерению KPI аналитиков в Agile-проектах". В рамках доклада мы посмотрим, как можно извлекать объективные и ценные данные о производительности аналитиков в реальных цифрах, не мешая команде работать.

Доклад будет интересен тем аналитикам и руководителям, кому важно уложить качественное выполнение работы в ограниченное время. Мы глянем теорию и увидим сложности ее применения, разберем примеры полезных KPI, посмотрим, какие сложности придется преодолеть для их внедрения, и оценим, стоит ли игра свеч. В результате вы получите пошаговый алгоритм выявления и формирования ключевых индикаторов производительности.

Расскажу об особенностях работы бизнес-аналитика в крупном банке, а также об  уникальных проектах, в которых принимают участие коллеги из направления бизнес-анализа, о процессах и о специфике работы.

Мы проводим регулярные онлайн-встречи с выходцами из системного анализа, которые поменяли свой карьерный путь. Хочу поделиться наблюдениями после разговоров с:

• b2b-продактом,
• архитектором и СТО,
• UX, CX-исследователем,
• техническим писателем.

В докладе расскажу о том:

• какие могут быть неожиданные пути развития системного аналитика;
• какие ключевые навыки выделяют эксперты, как самые необходиые;
• практических советах, что можно делать, чтобы развиваться в той или иной области (по факту совет будет однообразным независимо о роли): как находить ментора, полезные чаты, какие вопросы задавать экспертам у себя в компании и в профессиональных чатах, как искать полезные курсы и литературу.  

Доклад будет полезен больше всего джунам и миддлам

В жизнь системного аналитика стремительно вторгается микросервисная архитектура. В проектах с таким подходом системный аналитик должен описывать взаимодействия между сервисами, для чего необходимо иметь общее представление о типовых решениях подобной архитектуры. Часто аналитик принимает активное участие в проектировании системы, что требует еще большего объёма знаний. 

Доклад посвящён шаблонам микросервисной архитектуры, объясняется, как их читать и понимать. Также рассматривается выбор между микросервисами и монолитом, и поясняется влияние на этот выбор факторов тёмной материи и тёмной энергии.

Я Владелец Продукта в Банке. У меня 2 команды разработки и 2 продукта, которые я не владею, но отвечаю за то, как клиент с продуктом реализует все приложения CJM. Поэтому хочется узнать о том, как в результате возникает потребность, а также какие инструменты можно для того использовать, чтобы предложить хорошее открытие (без подробного изучения инструментов):

1. Составление продукта CJM

2. Работа с сигналами (просмотр и прослушка в текущих коммуникациях клиентов в Банке, сбор данных по обращению с различными обращениями, анализ рынка, изменения в законодательстве, экспертное мнение, исследования клиентов, количество исследований и отчеты)

3. Выявление проблем и предложений вариантов решений (через исследование и работу со СХ)

Выступление будет полезно тем, кто рассматривает свое развитие в отношении продукта PO/менеджера, и хочет изучить один из вариантов повседневной деятельности в корпоративном сегменте на данной позиции.